Сетевое решение в реализации архитектуры приложения

Даже из столь абстрактного описания логики игры можно сделать выводы о том, что архитектура приложения должна представлять собой несколько компонентов, взаимодействующих между собой в сети. Вот основные характеристики задачи, которые являются аргументами в пользу сетевого решения:

Таким образом, наше приложение имеет многокомпонентную, или так называемую многоуровневую архитектуру. Для таких задач типичным решением бывает обычно двух- или трехуровневая архитектура, когда приложение состоит из двух или трех типов взаимодействующих компонентов, среди которых выделяются: "обслуживающие" и "потребляющие" компоненты (серверы и клиенты). Серверный компонент может обслуживать от одного до нескольких клиентов одновременно. При необходимости вводят третий тип компонента — "промежуточный" серверный компонент между клиентским компонентом и основным серверным компонентом, чтобы разгрузить слишком нагруженный логикой обработки данных основной серверный компонент.

Замечание

Большее количество уровней встречается реже, обычно в области специализированных сетевых и коммуникационных задач.

Описанную архитектуру называют клиент-серверной. Наше приложение имеет такую архитектуру. Его разделение на компоненты выглядит следующим образом:

Access предоставляет две возможности для реализации приложений с такой архитектурой:

Замечание

Сетевое приложение Access может состоять и из одного компонента, не разделенного на части клиент и сервер, — одной базы данных с разрешенным общим доступом. Но это не эффективное решение.

В этой главе мы говорим о первом способе — сетевых базах данных.

Сетевое приложение Access "Игра в доминирование" должно будет обслуживать нескольких игроков — разных пользователей в сети. Предположим, пользователи работают в одноранговой сети. Рабочие станции пользователей, принимающих участие в игре, можно разделить на две категории: клиенты и серверы. На сервере выполняется ядро игры — управляющий компонент приложения. На клиентских рабочих станциях устанавливается компонент, предоставляющий пользователю интерфейс для участия в игре. Таким образом, приложение "Игра в доминирование" представляет собой распределенную базу данных Access с архитектурой "клиент-сервер", которая может быть использована даже в одноранговой сети. Все участники одной игры подключаются к одному серверу по схеме "звезда" (рис. 16.2).

Рис. 16.2. Архитектура приложения "Игра в доминирование"

Многопользовательский доступ к данным требует организации распределения этого доступа между пользователями и обеспечения защиты этих данных в соответствии.с правами пользователей. Все эти особенности сетевых приложений реализованы в нашем примере, а методы их реализации описаны в данной главе.